FIX: Avoid loss of precision when casting in packet loading (alternative) #786
Conversation
| _create_minimum_dtype_array( | ||
| list_of_values, dtype=datatype_mapping[apid][key] | ||
| ), | ||
| np.asarray(list_of_values, dtype=datatype_mapping[apid][key]), |
There was a problem hiding this comment.
Does numpy default to 64-bit floats? And if so, do we have any way to get the CDF products to use 32-bit floats where we want them?
There was a problem hiding this comment.
Yes and yes.
I am actually getting 32-bit floats in another packet definition where the floats are brought down directly in the telemetry stream, so space_packet_parser emits the Python floats and then we can use the bits to determine 32/64 bits correctly:
imap_processing/imap_processing/utils.py
Lines 264 to 269 in 87ede4d
This situation is purely for when a conversion factor gets applied and we just shrug and say, not much I can know about it from the packet definition since you told me it was unsigned 8 bits in the packet, but then you multiplied it by 2.5 and all bets are off for what you want me to turn that into (float, new int, string enumeration, ...).
Ultimately, this gets to your earlier suggestions though that this is really just a "first cut" and we should be putting dtype into the CDF metadata attributes yaml definitions and doing the casting there when creating the datasets and saving the products.
When using derived values there can be situations where a linear conversion factor is applied to a uint8 value to turn a raw measurement into a float temperature value for instance. These are represented as a small uint datatype onboard, but need to be represented as a float or larger integer datatype on the ground so we don't lose precision. Previously we were getting 2.1 cast to 2 after the derived types were attempted to be cast to their onboard types.
greglucas
force-pushed
the
min-dtype-fix-xtce
branch
from
c8da421
to
77b853a
Compare
greglucas
merged commit 164aca0
into
IMAP-Science-Operations-Center:dev
Change Summary
Overview
When using derived values there can be situations where a linear conversion factor is applied to a uint8 value to turn a raw measurement into a float temperature value for instance. These are represented as a small uint datatype onboard, but need to be represented as a float or larger integer datatype on the ground so we don't lose precision. Previously we were getting 2.1 cast to 2 after the derived types were attempted to be cast to their onboard types.
closes #780